メインコンテンツまでスキップ
バージョン: DAI 25.2

コンテナ内のEggplant DAIのデプロイ

ヒント

コンテナへのEggplant DAIのインストールを進める前に、組織内のエンジニアが認定Kubernetes管理者(https://www.cncf.io/training/certification/cka/)であるか、同等の経験があることを確認する必要があります。

Eggplant DAIはHelmを使用してKubernetesにインストールできます 以下の要件を満たす必要があります:

要件Notes
Kubernetes clusterテストバージョン1.29
ingress-nginxテスト済みバージョン 1.10.0 (チャート バージョン 4.10.0)。
Keda v2オプション、オートスケーリングエンジン用。 Tested version 2.13.2.
Eggplant DAI license必要に応じてサポートに問い合わせてください。

これらの要件を満たしたら、Helmの値ファイルを作成することで、デフォルトのEggplant DAIデプロイをインストールできます。 以下の例では、独自のデプロイ用にすべての値を置き換えます。

dai.yaml
global:
# Please omit the enclosing square brackets when you specify
# your licenses below. Including them can cause issues with
# the yaml file formatting.
devLicense: a-real-license-goes-here
execLicense: a-real-license-goes-here
featLicenses: comma-separated-feature-licenses-go-here


ingress:
host: dai.example.com

keycloak:
host: kc-dai.example.com
user: kcadmin
password: kcadminpassword

objectStorage:
minio:
rootUser: eggplant
rootPassword: eggplant


postgresql:
auth:
postgresPassword: postgres

keycloak:
auth:
adminUser: kcadmin
adminPassword: kcadminpassword
externalDatabase:
# This must match the value of global.postgresql.auth.postgresPassword
password: postgres

keycloak-user-provisioner:
adminUsers:
daiAdmin:
username: admin-username
password: admin-password
email: admin-email

いくつかの注意点:

  • global.ingress.hostglobal.keycloak.host は同じドメインである必要はありませんが、解決可能である必要があります。 これを行うには、クラスターに ExternalDNS のようなものをデプロイするか、レコードを手動で作成してクラスターに向けます。
  • コンテナで実行する場合は、DAI を TLS と組み合わせて使用する必要があります。 TLS は、イングレスに証明書を追加することでクラスター内で終了するか、外部ロードバランサーで終了できます。 詳細については、以下の TLS設定 セクションを参照してください。
  • global.ingress.host で設定するホスト名は、DAI専用に設定する必要があります。 同じサブドメインで他のアプリケーションを実行することはサポートされていません。
  • keycloak-user-provisioner.adminUsers.daiAdmin.password は12文字以上である必要があります。 keycloak-user-provisioner.adminUsersの下に追加のキーを追加することで、管理者ユーザーを追加できます。
  • DAI は、イングレス ルール内の構成スニペットを利用します 最新バージョンの ingress-nginx コントローラーを実行している場合は、これが allow-snippet-annotations に設定されていることを確認する必要があります。 これは、helm を使用して ingress-nginx をインストールする場合に controller.allowSnippetAnnotationstrue に設定することで実現できます。

すべての値の詳細なドキュメントはこちらで見ることができます。

次に、Kubernetesクラスタにそれをデプロイします:

$ helm upgrade --install \   --namespace dai \   --create-namespace dai \   oci://harbor.dai.eggplant.cloud/charts/dai \   --version 1.34.3 \   --values dai.yaml \   --wait Release "dai" does not exist. Installing it now. NAME: dai LAST DEPLOYED: Fri Feb 17 08:20:17 2023 NAMESPACE: dai STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Thank you for installing dai.

リリースの名前は dai です。

リリースの詳細については、以下をお試しください。

$ helm status dai $ helm get all dai

admin username: admin-username admin password: admin-password

警告

Helmチャートはこれらの依存関係をインストールしますが、PostgreSQLまたはMinIOに格納されているデータのバックアップは管理しません。 これらのサービスのバックアップは、ディザスター リカバリー計画の一部として、運用デプロイに配置する必要があります。 バックアップの 1 つのアプローチの例は、このドキュメントの後半にあります。

サポートされているカスタマイズ

デフォルトのインストールでは、PostgreSQLとMinIOのデータが永続ボリュームに保存され、すべての依存関係がKubernetesにデプロイされます。 PostgreSQLまたはAWS S3互換のオブジェクトストレージ用の既存のソリューションを代わりに使用したい場合は、Eggplant DAIのインストールをカスタマイズしてこれらを使用することができます。 さらに、セキュリティを向上させるために、値ファイルではなく Kubernetes シークレットを使用して資格情報を渡すこともできます。

ドキュメントのこのセクションでは、インストールをカスタマイズする方法を示す例を示します。 すべての例では、認証情報にシークレットを使用します。 すべての例は、上記で示したデフォルトのインストール値に追加することを意味するスニペットです。

オブジェクトストレージの設定

Eggplant DAIは、テストスクリーンショットなどのアセットを永続的に保持するために、S3互換のオブジェクトストレージソリューションに依存しています。 Helm チャートには、これを構成するためのいくつかのオプションがあります

バンドルされたMinIO(デフォルト)

デフォルトでは、Eggplant DAI Helmチャートはランダムなroot-userとroot-passwordでMinIOをサブチャートとしてデプロイします。

これらのランダムな値は、既存のシークレットを指定することでオーバーライドできます。 まず、次の資格情報を使用して既存のシークレットを準備します。

dai-objectstorage.yaml
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: dai-objectstorage
stringData:
root-user: username
root-password: password
$ kubectl -n dai apply -f dai-objectstorage.yaml

次に、既存のシークレットを指すように値ファイルを更新し、Helmアップグレードを実行します:

dai.yaml
global:
objectStorage:
minio:
existingSecret: dai-objectstorage

minio:
auth:
existingSecret: dai-objectstorage

$ helm upgrade dai oci://harbor.dai.eggplant.cloud/charts/dai --version 1.34.3 -f dai.yaml --wait

注意:global.objectStorage.minio.existingSecretminio.auth.existingSecret は一致する必要があります。

値ファイルの minio キーの下に値を渡すことで、MinIO インストールをさらにカスタマイズできます。 MinIOのインストールはBitnamiチャートによって提供されるため、利用可能なオプションについては、Bitnamiチャートのドキュメントを参照してください。

警告

Eggplantは、MinIOの設定の変更をサポートしていません。

既存のMinIO

既存のMinIOインストールがある場合、上記で作成した同じシークレットを使用して、次のように使用できます:

dai.yaml
global:
objectStorage:
minio:
existingSecret: dai-objectstorage
endpoint: my.minio.deployment.example.com

minio:
enabled: false

注: minio キーを使用して enabledfalse に設定します。これにより、バンドルされたMinIOのデプロイが防止されます。 This prevents the bundled MinIO from being deployed. This prevents the bundled MinIO from being deployed.

警告

DAIインストールの外部のMinIOインストールに対して、Eggplantはサポートを提供できません。

S3

AWS S3は、次のように既存のシークレットを使用してオブジェクトストレージに設定できます。まず、次の資格情報で既存のシークレットを準備します: First, prepare an existing secret with credentials in: First, prepare an existing secret with credentials in: まず、以下に認証情報を含む既存のシークレットを用意してください:

dai-objectstorage.yaml
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: dai-objectstorage
stringData:
aws-access-key-id: my-access-key-id
aws-secret-access-key: my-secret-access-key
$ kubectl -n dai apply -f dai-objectstorage.yaml

次のように、値ファイルを変更して、次のキーを更新または追加します。

dai.yaml
global:
objectStorage:
provider: "aws"
aws:
existingSecret: dai-objectstorage
awsAccessKeyIdKey: aws-access-key-id
awsSecretAccessKeyKey: aws-secret-access-key
region: "eu-west-1"

minio:
enabled: false

これで、Helm を使用してクラスターにデプロイできます。

PostgreSQL

Eggplant DAIはデータストレージのためにPostgreSQLを使用しています。Helmチャートは、それを設定するためのいくつかのオプションを提供しています。 The Helm chart provides several options for configuring it. The Helm chart provides several options for configuring it.

バンドルされたPostgreSQL(デフォルト)

デフォルトでは、Eggplant DAI Helmチャートはユーザー名とパスワードの両方を postgres に設定して、PostgreSQLをサブチャートとしてデプロイします。

これを上書きするには、次の資格情報でシークレットを作成します:

dai-postgres.yaml
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: dai-postgres
stringData:
postgres-password: my-access-key-id

値ファイルを変更して次のキーを更新または追加し、Helm を使用してクラスターに適用します。

dai.yaml
global:
postgresql:
auth:
existingSecret: dai-postgres

keycloak:
externalDatabase:
existingSecret: dai-postgres
existingSecretPasswordKey: postgres-password

keycloak.externalDatabase.existingSecretPasswordKey: デフォルトでは、Bitnami チャートは既存のシークレットがキー password の下にデータベース パスワードを持つことを期待していますが、Bitnami PostgreSQL チャートと DAI はデフォルトでキーとして postgres-password に設定されています。 上記のようにKeycloakチャートの動作を上書きするか、またはglobal.postgresql.auth.secretKeys.adminPasswordKeyを設定することができます。

PostgreSQLのインストールはBitnamiチャートによって提供されています。postgresqlキーの下でvaluesファイルにオプションを渡すことで、さらにカスタマイズすることができます。利用可能なオプションについては、Bitnamiのドキュメントを参照してください。 値ファイルの postgresql キーの下にオプションを渡すことで、さらにカスタマイズできます。 See the Bitnami documentation for available options.

extraEnvVars をオーバーライドする場合は、POSTGRESQL_DATABASE 環境変数も keycloak に設定する必要があります。 これにより、デフォルト値のkeycloak キーの下に設定されたKeycloakデータベースが作成されます。

警告

EggplantはPostgreSQLの設定の変更をサポートしていません。

既存のPostgreSQL

既存のPostgreSQLのインストールがある場合、またはAWS RDSのような外部サービスを使用したい場合は、それを行うことができます。

上記と同じ既存の秘密を使用して、次のキーを設定するようにvaluesファイルを変更します:

dai.yaml
global:
postgresql:
host: my.postgresql.host.example.com
auth:
existingSecret: dai-postgres

keycloak:
externalDatabase:
existingSecret: dai-postgres
existingSecretPasswordKey: postgres-password
host: my.postgresql.host.example.com

postgresql:
enabled: false

既存のPostgreSQLデプロイメントを使用する場合、これを使用するようにKeycloakの設定も更新する必要があります。

エンジンのスケーリング

Eggplant DAIのエンジンコンポーネントは、テストの実行とレポートの生成に使用されます。DAIインスタンスが忙しくなると、このコンポーネントをスケーリングして、より大きなテストボリュームを処理する必要があります。このスケーリングを管理するためにKedaを使用することをお勧めします。 DAI インスタンスがビジーになると、このコンポーネントをスケーリングして、より多くのテスト量を処理する必要があります。 このスケーリングを管理するには、Kedaを使用することをお勧めします。

Kedaを使用するには、まずupstream instructionsに従ってインストールします。

ヒント

サポートされているのはKeda v2のみです。

次に、valuesファイルに以下を追加してKedaを有効にします:

dai.yaml
ai-engine:
keda:
enabled: true

何らかの理由でKedaを使用できない場合、以下をvaluesファイルに追加して、エンジンレプリカの数を手動で管理することができます。イ ンスタンスが忙しくなるにつれて、それを増やします。

dai.yaml
ai-engine:
replicaCount: 2

Keycloak

Eggplant DAI は、認証および承認サービスに Keycloak に依存しています。 これはサブチャートとしてバンドルされており、現在、独自のKeycloakインストールの使用はサポートされていません。

Configuring TLS

コンテナでDAIを実行する場合、TLS証明書の使用は必須です ただし、DAI バージョン 7.3 以降では、プライベート認証局によって署名された TLS 証明書を使用できます 以下の カスタム TLS 認証局 (CA) の追加 セクションを参照。 TLSをどのように追加するかはユーザー次第であり、インフラストラクチャに依存する可能性があります これには、次のものが含まれます。

  • クラスタの外部にあるロードバランサーに TLS 証明書を追加し、そこで TLS 接続を終了する
  • Ingress-nginx コントローラーにワイルドカード証明書を追加して、すべての ingress ルール/ホストが共通の証明書を共有できるようにする
  • TLS 証明書を含む Kubernetes シークレットを DAI 名前空間に追加し、シークレットの詳細を値を介して DAI に提供します。

最初の 2 つのオプションはインフラストラクチャによって異なり、DAI 構成を変更する必要はありません。 DAIにTLS証明書を追加する場合は、次のことができます。

  1. 証明書とキーを PEM 形式で取得します。 証明書には、完全なチェーンが含まれている必要があります。

  2. DAI 名前空間に TLS を作成します。 (最初に名前空間を作成する必要がある場合があります)。

    kubectl create secret tls tls-secret --cert=path/to/cert/file --key=path/to/key/file -n dai
  3. DAI helm 値ファイルの ingress セクションを更新して、以下のように global.ingressglobal.keycloak の下に tls セクションを追加します (ホスト名とシークレット名をインストールに合わせて更新してください)。

    dai.yaml
    global:
    ingress:
    host: dai.example.com
    tls:
    - hosts:
    - dai.example.com
    secretName: tls-secret
    keycloak:
    tls:
    secretName: tls-secret
  4. 通常どおり Helm のインストールを完了します。

カスタム TLS 認証局 (CA) の追加

個々の DAI サービスは、リクエストの認証と承認に Keycloak を使用します。 これには、サービスが Keycloak エンドポイントに到達できる必要があります (構成されている TLS 証明書の検証を含む)。 DAI の各リリースには最新の CA 証明書が付属しており、ほとんどの公的に署名された証明書を検証できます。 DAI インスタンスが設定された TLS 証明書を確認できない場合は、global.ingress.customCACert 値を設定することで、helm 値を介して関連する CA を提供できます。

次のスニペットの例は、DAI に追加されるプライベート CA 証明書を示しています。 これにより、CA によって署名された TLS を DAI で使用できるようになります。

dai.yaml
global:
ingress:
host: dai.example.com
customCACert: |
-----BEGIN CERTIFICATE-----
MIIFYDCCA0igAwIBAgIJAL6zT1uUli/yMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMjQwNDEwMTQ0NTU3WhcNMjkwNDA5MTQ0NTU3WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC
CgKCAgEAyP3ve0Y3Y9Wh0G6dxWGQSdOPzVRgzv2adUV763GQOiEnSy8Z44X9rYNS
s6Yd80H5hDuHFPPTHeQdOQ+BVFlUqKT1nsVzDwwy9eApHLRiv3CXKE749sqRiFiQ
PwEGxk2zjRqOFm2phFKY81ikdazjd9Kl9bfdALrmJk6vFCHV3bwIgOFlkl42nWT+
cAnjZEo4p9pejKyccC/43L/BiVZ3ILYKmAhtQFgtBfX0STlV1eqvr0tKOU1WcHdb
AkUoWgmymEAqKOTgF3mptjeg2a+lAaXPMD25vUI5OZ3Kn+kGoL2bRM/3ujQdwv+0
reSvah2+XmJHeaGA3Mr00IGJF85H9YQDgrU9/nvJQX0NyDjO9Z4qViROU40nCMrf
41cBmD9e5DZL5bSyhAiNlbq0MplIvm2ervlvou6ymPfVkQmdet5rGNe3+XOFbamc
c2j65tgUm6+KSoho7xi+3PvmRDwgplTKLavcdZMHxjVWp6gQm6PVOxrheII+ZuIS
Au3ixVaN4anPRlV02EvkBu8Hf67faL6sL65kTYkL98BSdpIepJkHEBONv9DuCH9g
5jiGHXPyBkMuga7uxF6OTVR/SHd+io0ookbUyfuSIWywBBHvDu0cJG8CmrdptzCv
YBGg7fjz8IOrawOdv/3VVEzixe+qVr3HFT+eO3MMf9eNCo7M7U8CAwEAAaNTMFEw
HQYDVR0OBBYEFKSpIbnsb6Fff2dbiJYxLrtiyoGKMB8GA1UdIwQYMBaAFKSpIbns
b6Fff2dbiJYxLrtiyoGKMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQAD
ggIBAJD/rb1XpIXchX58dG6AV+uPtZ7ek1kqJHTA6fHW7UchZrtXW27HCraPnZ9m
hN/iiXxyflPWQFpndAWA3Zzor3eKZMPek5DvXa5yosC/2/kRlw+GkIXhrJEKvOaM
tIOXgKMuwZyLsYV5PD1Y3J1q+jx58euiZtsQRIDM8K7BuzmMruvWGXzxT2Vm54ZS
6s597X2YKlSu/34+G9a/8N9OqiULp+k0QKz/DXOpWXk8q9u95Ga2WExfsSH8H+ZW
2swVt9shdH5/L7Jbpm9Kq1acyI9WPh9oXDsGIcoWh10zblgqajIMzYX22tHjJc7M
GcoLubn9sSkJgqP46IfOngmbH2Ik9mDylXl11LPgrw8XudMh/Uf5RkvsJX9tAmib
IHrM2n0tSQiuZA16suABvGsmQkdhBzhFnpZJfgmxVXnEmwU8k2cUByil09ZoKtYw
7YvMz+p+uFdl+uoOhWOLbfSftymMkeHNRdykiNCXqCjPzZgHVwHCCIPIDWpIbb7w
qkzoUw6dp1YOz4RO0ZsJ7zhztSsSGHinvbH1TnXzdCj1OjkP612/lRJB3NC99rbg
HFKMUeiXEtZbMtTYaBxJ9vWxtkbeVwaWZommZVjDk6kYFiUsShij9olN78JcZB6/
2TxFcGsToiq0hJQ19soqTKuBP79TCpeQpOQj/glYB8MZbU+R
-----END CERTIFICATE-----

ノードセレクタの設定

ノードセレクターは、Helm値を介して追加し、DAIサービスを実行するKubernetesノードを制御できます。 すべてのDAIサービスのノードセレクターを設定するには、値にglobal.dai.nodeSelector を設定します。 DAI はサードパーティのコンポーネントも使用するため、これらは値ファイル内で個別に設定する必要があります。 以下の例のスニペットは、ノードセレクターが、すべてのDAIサービスおよびPostgresql、Rabbitmq、Minio、およびKeycloakサブチャートでnode-pool=application というラベルのノードのみを使用するように設定できることを示しています。

dai.yaml
global:
dai:
nodeSelector:
node-pool: application

postgresql:
primary:
nodeSelector:
node-pool: application

rabbitmq:
nodeSelector:
node-pool: application

minio:
nodeSelector:
node-pool: application

keycloak:
nodeSelector:
node-pool: application

バックアップと復元

DAI インストールからの構成データと結果データを定期的にバックアップする必要があります。 バックアップが必要なデータは、PostgreSQL(DAIおよびKeycloak用に構成) とオブジェクトストレージに保存されます。

このデータのバックアップ方法は、デプロイメントの設定方法によって異なりますが、ここでは、このドキュメントの冒頭に示されているデフォルトのインストールで両方をバックアップする方法の例を示します。

PostgreSQLのバックアップと復元

Eggplant DAIは複数のデータベースを使用してデータを保存するため、すべてのデータベースを確実にバックアップするために、デフォルトのインストールでは pg_dumpall を使用することをお勧めします。 共有データベースインスタンスを使用している場合は、次のデータベースをバックアップする必要があります。

  • execution_service
  • keycloak
  • sut_service
  • ttdb
  • vam

以下の例では、デフォルトのPostgreSQLポッド内で pg_dumpallを直接実行します。結果は、ローカルコンピューターの dai.dumpファイルにストリームされます: 以下の例では、デフォルトのPostgreSQLポッド内で pg_dumpallを直接実行します。結果は、ローカルコンピューターの dai.dumpファイルにストリームされます: The result is then streamed to dai.dump file on the local computer: その後、結果はローカルコンピュータ上の dai.dump ファイルにストリーミングされます。

$ kubectl --namespace dai exec postgres-0 \
-- /bin/sh -c \
'export PGPASSWORD=$POSTGRES_PASSWORD && pg_dumpall --username postgres --clean' \
> dai.dump
警告

The command given here includes the --clean option. これにより、pg_dumpall には、ダンプ内のデータベースを削除するコマンドが含まれます。 これにより復元が容易になりますが、これが発生することを知っておく必要があります。

実際には、次のことをしたいでしょう:

  • ダンプを圧縮する
  • バックアップストレージサーバーに配置する
  • スケジュールに従って実行する。

ただし、pg_dumpallの使用はそのまま維持されます。

バックアップを復元するには、次のようにプロセスを反転させることができます:

$ kubectl --namespace dai exec postgres-0 \
-- /bin/sh -c \
'export PGPASSWORD=$POSTGRES_PASSWORD && psql --username postgres \
--dbname postgres \
--file -' < dai.dump

いくつかの注意点:

  • -We used the --clean option when creating the dump. これは、バックアップ内のすべてのデータベースが削除され、再作成されることを意味します。
  • -We specify --dbname postgres. バックアップは --clean で作成されているため、復元の一部としてドロップされるデータベースの 1 つに接続するとエラーが発生します

MinIOのバックアップと復元

画像やその他のアセットは、データベースではなくオブジェクトストレージに保存されます。 上記で説明したデータベースの内容に加えて、これらをバックアップする必要があります。 このバックアップをローカル マシンから実行する簡単な方法を以下に示します。 次の例では、MinIOクライアントツールをローカルにインストールする必要があります。

$ ROOT_USER=$( kubectl get secret dai-objectstorage -o json | jq -r '.data."root-user"' | base64 -d )
$ ROOT_PASSWORD=$( kubectl get secret dai-objectstorage -o json | jq -r '.data."root-password"' | base64 -d)
$ kubectl port-forward service/minio 9000:9000 &
$ PID=$!
$ mcalias set minio <http://localhost:9000> $ROOT_USER $ROOT_PASSWORD -api S3v4
$ mkdir backup
$ mc cp --recursive --quiet minio/ backup/
$ kill $PID

前回と同様に、バックアップを圧縮し、適切なストレージサーバーに移動して、スケジュールに従って実行することをお勧めします。

バックアップを復元するには、コピーコマンドを逆にするだけです:

$ mc mb minio/assets
$ mc mb minio/screenshots
$ mc cp --recursive --quiet backup/ minio/

これは、デフォルトの設定でアセットバケットとスクリーンショットバケットを分けて使用していることを前提としています。その場合は、復元する前に「mc mb」でバケットを作成する必要があります。

アップグレード

アップグレードの一般的な手順は、任意のHelmリリースと同じです:

  • PostgreSQLデータとオブジェクトストレージデータをバックアップします。
  • 1.PostgreSQLとオブジェクトストレージのデータをバックアップします。 2.helm repo updateでリポジトリを更新します。 3.バンドルされたMinioを使用している場合、Minioのデプロイメントのルートユーザーとパスワードを取得します。 4.Keycloakのデプロイメントのルートユーザーとパスワードを取得します。 5.既存の値を取得し、必要な新しい値に変換します。 6.helm uninstall -n dai daiで古いデプロイメントをアンインストールします。 7.さらに、kubectl -n dai delete jobs --all && kubectl -n dai delete pvc --allで古いPVCとジョブをすべて削除します。 8.次のようにしてHelm 6.5のリリースをインストールします:
  • helm get valuesとテキストエディターで新しいリリースの必要に応じて値を変更します。
  • helm upgradeを実行します。

Each Eggplant DAI release may have specific additional steps. そのため、この手順を適用する前に、実行しているアップグレードについて以下の注意事項を確認してください。

DAI 25.1 から 25.2 へのアップグレード

上記の一般的なガイダンス以外に、25.1.x から 25.2.x へのアップグレードについて実行する必要がある特定の手順はありません。

アンインストール

Eggplant DAIをhelm uninstallでアンインストールするか、それをインストールした名前空間を削除することでアンインストールできます。

PostgreSQL インスタンスや S3 バケットなどの外部リソースを使用するためにカスタマイズを適用した場合は、これらを個別に削除する必要があります。

完全なドキュメントは、Eggplant DAIチャートでサポートされているすべての値を示しています。

サポート

さらなるサポートが必要な場合は、Eggplantカスタマーサポートに連絡してください。